TPUG - Toronto PET Users Group/TPUG Users Group CD/TPUG Users Group CD.iso/AMIGA/AMICUS/AMICUS02.ADF/Tutorials/Animate

Text File | 1989-05-30 | 13KB | 283 lines

TITLE: GELS and Sprites

ON SPRITES, BOBS AND GELS -- John T. Draper (Captain Crunch)

   Last time,  I covered an overview on sprites, Bobs and Gels.   Now I'm
going to show how they are all related.

   On the lowest level,  there are 8 hardware sprite generators.  These are
hardware components which are controlled by storing data into registers. Each
sprite is 16 pixels wide,  and can be any height.   Normally, you don't have
to worry about  directly controlling the hardware sprites.   There are
routines in "graphics.library" called VSprites ( Virtual sprites ) which
control the hardware sprites.   This, in effect, appears that you have an
unlimited set of sprites with which to work.

   There are certain restrictions which apply to the use of these sprites.
You can only have four sprites across a scan line at any one time. As the
lines are scanning across the screen,  they eventually will scan across where
a sprite is to be placed.  In order to efficiently use the hardware sprite
generator,  the sprites MUST be in a certain order.

    -----------------      <-- Sprite A gets grabbed as scanline reaches it
    |               |
    |               |
    |  sprite A     |        -----------------   <-- Sprite B gets grabbed
    |               |        |               |       Now there are 2 sprites
    |               |        |               |       in use.
    |               |        |   sprite B    |
    -----------------        |               |   <-- Sprite A gets released
                             |               |       Now there is ONE sprite.
                             |               |       in use.
                             |               |
                             -----------------   <-- Now sprite B gets released

    If you are stealing hardware sprites,  you are effectively stealing two
(even-odd) sprite pairs.  0/1,  2/3,   4/5,   and  6/7,  which share the same
color registers.   So,  IF you are working at this low level,  you should
grab a pair of sprites.   Because you are not granted exclusive use of the
color registers and the hardware sprites,  you should release the sprites
immediately.   Remember!!  You normally WON'T be working at this low level,
but it's important that you understand it so you can deal with the
limitations. Example code on page 9-11 in the Rom Kernal manual shows the use
at this low level.   I Caution you that this code WON'T work the way it's
written,  but shows you an idea how to handle the simple sprites.

   The relationships between simple sprites, Vsprites,  Bobs, and Gels are as
follows.   Lets start at the highest level this time and work down to the
simple sprite.

   Any object on the screen such as the robots in "Robot city" are called
GELS. (Graphic ELementS ).   A GEL can be a man walking across the screen and
includes ALL positions of the animated man.

   Included within a GEL is an AnimOB (animated object), which comprises of a
series of AnimComp's or each animated "Position" or "Frame" of the object.
These frames are linked together in a linked list which are handled by the
"Exec" or multi-tasking system.   Again, they have to be in some kind of
order.

   AnimComps are animated components which are an expansion of the Bob.  A
Bob (Blitter OBject) is an extension of the Vsprite.   It uses a combination
of the simple sprites (Hardware),  and "Blitter" (A fast memory move engine
implemented in hardware),  to "Stamp" the sprite on the screen using the
video co-processor called the "Copper".

  Each "level",  from the simple sprite to the GEL uses their own data
structure which links to the other data structures.   Some people were making
comments about why the RastPort and the Viewports weren't combined into ONE
structure.   I would assume they (Amiga) wanted to keep every level separate.
Links do this nicely.

DISPLAYING VSPRITES
-------------------

Here is a quick summary of what it takes to display Vsprites and/or Bobs.

o Define a View structure by opening up a screen and/or a window.  Using
  OpenScreen then OpenWindow (Optional) from intuition.

o Specify the RGB Colors registers for the Viewport, using:
  SetRGB4(&Viewport, num, r, g, b),
where: num = Color number from 0 to 31
r = Red level g = green level b = blue level.

Normally, the Preferences program sets this up.  This is OPTIONAL.

o Allocate memory for your borderline bitplanes.  Also Allocate memory to
  store the image behind the sprites,  and other necessary bit images.

o Initialize the GELS, by calling:  InitGels(&spriteA, &SpriteB, &Gelsinfo)
  spriteA - Pointer to the Vsprite structure used as list head.
  spriteB - Pointer to the Vsprite structure used as list tail.
  Gelsinfo - Pointer to the GELSInfo structure to be initialized.

o Define the sprite(s)
  - Height(s)
  - Onscreen Position(s)
  - Where to find Image data
  - Where to find SprColors to use
  - Set up Vsprite structure flags that show this is Vsprite.
  - Set MUSTDRAW (A flag) if it MUST be drawn.

o Add the Vsprite to the GEL list.  Call:  AddVSprite(VS, RPort)
  VS = Pointer to Vsprite structure.   IE: Vsprite *VS
  RPort = Pointer to a Rastport Structure.

o Change (Or set) the VSprite appearance by changing pointer to the Image data
  and its height.  This is done by accessing Imagedata and SprColors fields
  in the Vsprite structure.   If VS is a pointer to a Vsprite structure,  then:

  VS->ImageData = &MynewData   Where MynewData points to the new data.
  VS->SprColors = &MyColors    Where MyColors points to new "data" colors.

o Move the sprite by defining a new Y,X Position.  If VS is a pointer to
  the VSprite structure,  then:

  VS->X = 23
  VS->Y = 45

  Sets the position to 23, 45.   You also can look at the previous position

  Prevx = VS->OldX
  Prevy = VS->OldY

o Now you can display the Vsprites with this sequence of routines.

  ON_DISPLAY;   <-- Enables the system direct memory access to Playfield
                    display.

  ON_SPRITE;    <-- Enables system DMA for access to Vsprites.

  SortGList(&rastport);  <-- Sorts the GELS in order for efficient access.

DrawGList(&rastport, &viewport);  <-- Looks through sorted list, Prepares
  necessary instructions and memory areas to display the data.  DOES NOT
  ACTUALLY DRAW ANYTHING ON SCREEN,  It draws into the RastPort.

  MrgCop(&myview);  <-- Merge together "Copper" instructions.

  LoadView(&myview) <-- Executes the "Copper" instructions as layed out in
    the previous function.   THIS ACTUALLY DISPLAYS THE SPRITES.

There is a lot of clean-up to do when done with your program.  You must
release the memory used by your buffers by de-allocating them.  Remember to
CloseScreen, and CloseWindow (If you opened one).
}


Name: BLITTER TUTORIAL
Type: DOCUMENT
Date: 7-NOV-1985 22:02 by CRUNCH
Size: 5537

This is a tutorial on the Blitter and Amiga Animation.  it explains some of the
blitter features, and the functions performed.

Keywords: GENERAL, BLITTER, ANIMATION, CRUNCH, DRAPER

ACTION> (Next, Down, Xm, List) list
TITLE: Blitter, Sprites, and animation

AMIGA BLITTER AND SPRITES
-------------------------

        Starting from the hardware and working up into "Intuition",  here is
a quick summary on how everything is put together.

        The Amiga has a high performance graphics engine that uses up to four
DMA channels.   This is the foundation for a higher level animation system.
Once the blitter registers are set up,  data copying and line drawing are
done in hardware and independently of the 68000 CPU.   Below is a quick
summary of blitter features and the operations they perform:

** DATA COPYING - of bit plane images anywhere

** MULTIPLE SOURCES - Up to 3 sources of data can be processed,  and then
        the results can be placed in a destination area.

** LOGIC OPERATIONS - Up to 256 logic operations on the 3 data sources can be
        performed.

** MULTIPLE MODULOS - For each of the sources which allow data to be moved
        to and from identical rectangular windows within different sizes of
        larger playfield images.

** ASCENDING AND DESCENDING ADDRESSES - Bottom to top and vice versa.

** SHIFTING - Up to 15 bits is permitted before applying the logic operations.

** MASKING - The leftmost and rightmost data word can be masked which allow
        operations on bit-boundarys.

** ZERO DETECTION - Used for collision detection, because the results of the
        logic operations can be sensed.

** AREA FILLING - Between pre-drawn lines.

** LINE DRAWING - At any angle.

        The "blitter" is very efficient at copying such blocks because it
only needs to be told the starting address, Dest address, and the size of the
block. It is important to note that the addresses MUST be within the FIRST
512k section of memory.  I am not certain if the Lattice C compiler is smart
enough to place code outside of that area, thus freeing that special addess
space for larger programs.  When the memory moves are complete, the processor
is signaled with a flag and an interrupt.

        Listed in the Hardware manual is a set of logical formulas (There are
lo to achieve just about any logical operations on the pixels.   The SPRITE
generator uses the "blitter" hardware to generate sprites, icons, and the
other graphics objects.

        Blitter uses "modulos" to allow manipulation of smaller images within
la images.   There are four modulos in the Blitter.  This allows all three
sources, and the dest to each have different sizes.

        On top of this hardware foundation are the Sprites.  Normally,
"blitter is controlled from a higher level using a data structure called a
"blitter-node" The system can link these together into a FIFO queue.  When
your turn comes up to process an object, sprite or whatever,  your own
routine can be repeatedly called until your routine says its finished using
the blitter.

        There are actually 2 separate queues formed.  One called QBlit,
which is used when you want something done, and don't care when it happens,
and the other QBSBlit which means "queue beam synchronized" blitter
operations.   This beam synch takes precedence over the simple FIFO.

        The bltnode data structure is:

        struct  bltnode
        {
                struct  bltnode *n;             /* Pointer to next bltnode
                int             (*function)();  /* Address of function when its
                char    stat;                   /* whether or not to "clean up"
                short   beamsync;               /* VBEAM counter value
                int             (*cleanup)();   /* Your clean-up function
        };

SHORT INTRO TO animaTION
------------------------

        Here is a short intro to the animation routines available on the
Amiga. I won't go into detail because it's already about 3:30 am, So I will
briefly cover it.   You can mail me if you want more details.   Basically,
the animation routines let you define images called GELS (Graphic ELements).
 Each GEL has the following characteristics:

** Height
** Width
** colors
** shape
** Position in the drawing area
** How to draw it
** How to move it
** How it interacts with other elements.

        Before you can use GELS, you must have prepared a VIEWPORT as
described in an earlier article.   Then you call:  InitGels();  This sets up
two "dummy VSPrites" which are used as the "head" and "tail" elements in the
system list of GELS.   You can the ADD and DELETE your GELS from this list.

        There are two types of animation one can perform on the AMiga.

** Sprite animation - Sprites are 16 pixels wide, and as high as you like.
        Check out "robot city" and examine the screen carefully.

** Playfield animation - is a technique one can use to modify sections of a
        background area (Playfield).   "Blitter" does the dirty work.

        This is a brief overview of the animation software,   there is more of
course,  but this can give you an idea of what to expect.   There are simple
sprites,  Vsprites, Bobs (Blitter Objects), AnimCOmps, and AmimObs and each has
its own data structure or is the part of larger structures.

        For example:  MoveSprite (viewport, sprite, x, y);  Moves the sprites
in any direction.  In the ROM Kernal manual (Where most of this info was
derived) there are source code examples in C which describe how to control the
sprites, GELS and other objects.